CD Ware Multimedia 1994 November

home *** CD-ROM | disk | FTP | other *** search

/ CD Ware Multimedia 1994 November / Cd Ware (Nro. 2) - Epimundo.iso / DOS / CM / PI_100P.ZIP / POSTIT.DOC < prev next >

Wrap

Text File | 1994-06-13 | 27.4 KB | 514 lines

██████╗ ██████╗ ███████╗ ████████╗ ██╗ ████████╗ ██╔══██╗ ██╔═══██╗ ██╔════╝ ╚══██╔══╝ ██║ ╚══██╔══╝ ██████╔╝ ██║ ██║ ███████╗ ██║ ██║ ██║ ██╔═══╝ ██║ ██║ ╚════██║ ██║ ██║ ██║ ██║ ╚██████╔╝ ███████║ ██║ ██║ ██║ ╚═╝ ╚═════╝ ╚══════╝ ╚═╝ ╚═╝ ╚═╝ Copyright (c) 1994 Mark Lewis Quartz Crystal Software ┌────────────────────────────────────────────────────────────────────────────┐ │░░░▒▒▒▓▓▓ A Few Words From The Author ▓▓▓▒▒▒░░░│ └────────────────────────────────────────────────────────────────────────────┘ PostIt was originally developed because something was causing the MSGHDR.BBS file in my Hudson Message Base to become corrupted and I didn't know what. At that time, it could have been the fault of the MBUtil from the shareware version of GEcho v1.00 that was causing it. I'd experienced other unexplained problems with that version of GEcho that went unanswered by the author and this particular problem seemed to happen only after MBUtil posted a text file. We'd soon see as this program was written to replace the posting function of MBUtil and FTools since FTools post function also seemed to be NetMail only at that time. I still have not figured out where the problem was since I have not experienced it at all after this utility came online. Even in its most primitive form, PostIt has proven to be an extremely reliable performer. PostIt's command line parameters may seem a bit overwhelming and intricate. Unfortunately, because of the capabilities of PostIt and the many uses that it may be called into, this is necessary. After working with PostIt for a while, the command line paramters will come naturally. One thing to keep in mind, though, is that PostIt is designed as a "Set it and forget it" utility. In other words, you set it up in your .BAT files and forget about it. Once it is set up correctly, it will perform its task with undying devotion. ┌────────────────────────────────────────────────────────────────────────────┐ │░░░▒▒▒▓▓▓ The Configuration File ▓▓▓▒▒▒░░░│ └────────────────────────────────────────────────────────────────────────────┘ The configuration file must be named POSTIT.CFG and located in the same directory where POSTIT.EXE is located. Without it, PostIt will not operate unless you are operating it in RemoteAccess Compatibility Mode. There must be at least one message base type defined in the config file. The RemoteAccess Compatibility Mode is only operational if you tell PostIt to post the text file in board Rx (ie: -BR1) where 'x' is the board number in your MESSAGES.RA file. In RA Compatibility Mode, all necessary information is taken from the RA config files. Yes, both HMB and JAM support are available. PostIt only supports RA versions 2.xx. Sorry, no support is planned for older versions of RA. The MSG directory definitions are the directories where the *.MSG files are located. These files make up FIDONet's oldest message base format. You may define up to twenty MSG areas. The HMB definition is the directory in which the Hudson Message Base resides. This is the directory in which the MSG*.BBS files are located as well as the ECHOMAIL.BBS and NETMAIL.BBS files that indicate which messages need to be exported my your mail tosser, if you are running in a mail network. You may define only one HMB area. The SQU definitions are the complete path and base name of the SQUISH type message areas. Since the definition includes the base name of the areas, they can be up to eight characters in length. You may define up to twenty SQU areas. The EZY definition is the base directory from which the EZYCom Message Base areas will reside. I'm not familiar with EZYCom and can only rely on information received from EZYCom sysops and the library code I am using. It appears that the EZY definition is to be the base directory from which all the EZYCom areas are built from. EZYCom areas seem to be divided into groups of up to one hundred areas with each group of one hundred being located in a dedicated AREA???? directory, two files per area. You may define only one EZY path. The JAM definition is similar to the SQUISH definitions. The areas are defined by specifying the complete path and base name of the JAM type message areas. The same restrictions about the base name are in effect, up to eight characters are allowed. JAM echomail and netmail areas also have files similar to the HMB ECHOMAIL.BBS and NETMAIL.BBS export indicators. These files for JAM areas have the same names but the extension is .JAM instead of .BBS. The JAM bases were introduced with RemoteAccess version 2.00 BBS software. RA creates the ECHOMAIL.JAM files in the same directory as it creates the ECHOMAIL.BBS files. This directory is the path defined in RA's setup as the message base path and is the directory in which RA's HMB and user files are located. If you are using the RA Compatibility Mode, PostIt will place these .JAM files in the defined message base path just as RA does. If you are not using RA Compatibility Mode, the creation of these files will be skipped. You may define up to twenty JAM areas. Message posting size may not be a question for you and your setup. However, I feel that you should know that PostIt does have "some" limitations in its capability to post large files. MSG - unlimited size (will use up to 4Gig of diskspace for temp buffer) JAM - unlimited size (will use up to 4Gig of diskspace for temp buffer) SQU - approximate 32K limitation HMB - approximate 16K limitation EZY - approximate 16K limitation The above limitations are imposed by the library of routines that I am using. They may be removed or increased in size in future versions of the routines or PostIt. At this time, PostIt will just truncate any postings over the above stated limits without notification. If the postings are EchoMail, your mail tosser will have to place the TearLine and Origin Line on the exported messages. Future versions may also allow automatic detection and splitting of overly large postings. Only time and registrations will tell. One should note that the above testing was done by having PostIt post the entire 2.4Meg FIDONet NODELIST.056 as a message <<GRIN>>. What your mail tosser or BBS Software does with it when it gets it is another matter. If you are a member of a message network such as FIDONet, you will also need to define your network address(es) if you are going to be using PostIt to post messages that will be exported to other systems via echomail or netmail. These address definitions may contain address numbers as high as 65535. Using zones over 255 could cause problems if posting to HMB netmail areas due to the design feature of the HMB that only allows for zones up to 255. The largest address supported by PostIt is 65535:65535/65535.65535. There may be other restrictions similar to the Zone problem in the HMB that could occur in the other message base types and BBS Software. Please be aware of this. Some software uses integers which generally count from 0 to 32767. Numbers greater than this maximum limit will roll over and start counting backwards with negative numbers. For example, the above address, when read by other software that uses integers, will appear to be from -1:-1/-1.-1 which appears to be incorrect. How other software handles this is between you and that software author. Part of the confusion comes from documents that tell how certain things are implemented in FIDONet. Some of these documents leave a lot to be desired and have very broad interpretations associated with them. You may define up to ten address entries. This may be expanded to handle more in the future but this depends greatly on what happens with other software. Origin lines are another feature used in FTN message networks. They, as their name implies, show where the message originated. Origin lines may not be longer than seventy-eight characters long. PostIt allows you to define up to twenty origin lines. These origin lines may only be up to fifty characters long. Any characters over the fifty character mark are lost. Since the length of the address must also be taken into account when generating the origin line in the message, PostIt may trim some more characters from the defined origin lines as defined in the POSTIT.CFG file. This is better than just letting overly long origin lines get out into the networks or chopping part of the address off as some broken mail handling software likes to do. Note that PostIt will place the ' * Origin : ' and the '(zone:net/node.point)' portions of the origin lines in the origin lines. You should not define these parts in your origin line definitions. Below is a copy of the sample POSTIT.CFG file that is included in the release archive. It defines a couple of each type of message area that PostIt supports. This is only to show that PostIt can write to any of them. If your system does not use an area type, you do not have to define it in the config file. This is also true for the address and origin line definitions. ; PostIt v1.00PR Config File ; Lines beginning with a ; (semicolon) are comments and are ignored. ; Comments CANNOT be on the same line as a config entry. ; Blank lines are also ignored. ; At least one of the messagebase types HMB, EZY, SQU, JAM, or MSG is ; *REQUIRED* unless you are using the RA configuration. ; only one HMB area path is allowed HMB=g:\fd\msgs ; only one EZY area path is allowed EZY=f:\tp\postit\msgs\ezy ; max of 20 MSG area names MSG=f:\tp\postit\msgs\msg\alpha MSG=f:\tp\postit\msgs\msg\beta MSG=f:\tp\postit\msgs\msg\gamma ; max of 20 SQU area names SQU=f:\tp\postit\msgs\squ\alpha SQU=f:\tp\postit\msgs\squ\beta SQU=f:\tp\postit\msgs\squ\gamma ; max of 20 JAM area names JAM=d:\tp\postit\msgs\jam\alpha JAM=d:\tp\postit\msgs\jam\beta JAM=d:\tp\postit\msgs\jam\gamma JAM=d:\tp\postit\msgs\jam\epsilon ; default system address, *REQUIRED ONLY IF POSTING ECHOMAIL OR NETMAIL* and ; not using the RA configuration files. if you are using the RA configs, ; PostIt will read these from them... ; max of 9 additional AKA's ... this makes 10 total AKA's available. ADDRESS=1:3634/12 ADDRESS=1:3634/12.99 ; origin lines - max of 20 origin lines ; the origin line will be empty unless you specify to use one of these or ; are using the RA configuration files. if you are using the RA configs, ; the origin line used will be the one defined for the area posting to. origin=fair haired bluebottle flies origin=zippy sez, "Yow!! I'm in a PURPLE Phase!" origin=i'm a palindrome | emordnilap a m`i origin=stressed desserts ; end of config file I'm sure that there are some of you now asking, "What about Tearlines?" Well, the short answer is that PostIt uses the ^aPID: line instead of tearline program identification. Postit will always use a clean tearline when it adds one to a posted message. If you use the -Notear command line parameter, PostIt will not add a tearline to the posted message. I've allowed this behavoir because tearlines are not specifically required in echomail messages, according to some interpretations of FIDONet Technical Specifications, and I'm totally against adding a lot of extra stuff to messages that others have to pay to move around the globe. You may also force a Tearline to be added to netmail messages with the -Forcetear command line parameter. This so that you can post automated AREAFIX messages. Some AREAFIX programs will choke if there is no tearline telling them where the end of the message is. This also brings us to allowable characters in messages. In FIDONet, the specifications state that ASCII characters 0 thru 29 are not allowed in the BODY of messages. This does not apply to the Carriage Return, Line Feed and TAB characters. ASCII characters over 127 are also not allowed in message bodies, according to specifications. This last part, however, may not be enforced in certain mail network conferences due in part to their use in other languages as part of their normal language character sets. These restrictions do NOT, however, apply to the message HEADER, according to FIDONet Specifications. Yes! There are seperate parts of a message! The message header is generally the TO:, FROM:, SUBJECT: lines, the network originating address, the network destination address and the date and time that the message was posted. There may be other information pertinent to a message that cold also be included in the header. "How does the above technopolitical stuff relate to PostIt," you ask? PostIt does not care about character sets. It happily posts pretty much anything that you feed it. It is up to YOU to use allowable characters in whatever mail network conferences that you may configure PostIt to post messages in. ┌────────────────────────────────────────────────────────────────────────────┐ │░░░▒▒▒▓▓▓ The Parameters ▓▓▓▒▒▒░░░│ └────────────────────────────────────────────────────────────────────────────┘ The parts inside the <>'s are NOT to be used. They are only for clarification of what the parameters mean. They are not optional or required. -M<essage> the name of the file to post. * REQUIRED * -B<oard> message base type and board number to post in. * REQUIRED * -S<ubject> the subject line of the message. (default is filename) -F<rom> FROM: name (default is SysOp, except in NetMail or EchoMail) -T<o> TO: name (default is ALL, except in NetMail) -Ax where x is which address in the .CFG file to use. -Ox where x is which Origin Line in the .CFG file to use. -Dxxxxxx where xxxxxx denotes a valid FTN style destination address. * REQUIRED for NetMail messages * -Pvt denotes a Private message. -Net denotes FTN NETMAIL. -Echo denotes FTN ECHOMail. * otherwise Local with NO Tear Line and Origin Line * -Notear do not add a Tearline to a posted ECHOMail message. -Forcetear force adding of the Tearline to a posted NETMail message. -B<oard> has the following parameters Hx : Hudson Area, x is the area number in your BBS setup Mx : *.Msg Area, x is the area number in the .CFG file Sx : Squish Area, x is the area number in the .CFG file Ex : EZYcom Area, x is the area number in the .CFG file Jx : JAM Area, x is the area number in the .CFG file Rx : Use Area x definition from your RemoteAccess configuration If the RA environment variable is set, the directory that it points to will be searched for the CONFIG.RA file. This file tells us where the Message Base Path is that RA places the ECHOMAIL.JAM and NETMAIL.JAM files in. If the posted message is a NetMail or EchoMail message stored in JAM format, we''ll create or append to these files as necessary for your mail tosser to be able to scan them out without having to scan all your JAM areas. The RA message area configs will only be used if you tell PostIt to use them. Otherwise, all necessary information is expected to be located in the POSTIT.CFG file. All message area numbers are 1 based unless there is only one listed in the config. This does not apply to HMB areas or when using the RA message area config file. Both of them start a 1. an example : -BJ, -BJ0 and -BJ1 are all the same area. I felt that it was easier to type -BJ than to have to type -BJ1 or -BJ0 if there was only one JAM area listed in the config file. This works the same for all areas except for HMB areas which have their area number stored in their message header. There is NO area 0 in a Hudson Message Base or in the RA message area configuration. ┌────────────────────────────────────────────────────────────────────────────┐ │░░░▒▒▒▓▓▓ Some Error Messages ▓▓▓▒▒▒░░░│ └────────────────────────────────────────────────────────────────────────────┘ No Message Board Number Specified! Which Messagebase Type? [H]udson, [M]sg, [S]quish, [E]zycom, [J]AM, [R]A Only numerical Message Board identifiers are allowed! A message cannot be both ECHOmail and NETmail! Hudson Area numbers cannot be over 200! NETMail messages =require= a destination address! NetMail and EchoMail messages cannot be From: SysOp! NetMail messages cannot be To: All! Cannot locate CONFIG.RA! Incorrect CONFIG.RA Version ID! Cannot locate MESSAGES.RA! Message area number specified out of range in config file! This is not possible! Originating address cannot be greater than 'x'! PVT messages cannot be To: All! Ezycom Area numbers cannot be over 1024! Do any of these really need any explanation? ┌────────────────────────────────────────────────────────────────────────────┐ │░░░▒▒▒▓▓▓ The Error Levels ▓▓▓▒▒▒░░░│ └────────────────────────────────────────────────────────────────────────────┘ PostIt traps for over 50 different errors. Some of these errors are configuration errors. Others are possible program and compiler errors. Still others are just general failures. PostIt will report these errors on the screen and delay for up to ten seconds or a key press. Some errors are specific to the different message base types and all will have the first character of the message base type as part of the error code. There is no log file for PostIt. The code is already over 100K and I do not want to add a lot of additional code to handle a log file that could also introduce other errors and problems. (ie: no diskspace). These error codes are grouped into only four errorlevels that PostIt will exit with in the event of a problem. These error levels are... 1 : a necessary file is missing 2 : bad parameters either on the command line or in the config file 3 : a runtime error 4 : overlay error Error levels 1 and 2 can be handled by you by checking to make sure that all necessary files can be found, by carefully going over your command line and the settings in your config file, if you are using one. Error level 3 is the most "hazardous" of the error groups being tracked. It will probably require me to take a look at the code to determine exactly what happened if you are unable to do so on your own. Tracking level 3 errors requires that you write down everything on the screen so that you can get it to me for troubleshooting. I need the exact error code and the text associated with it. I may also need to know what progress prompts are on the screen as certain errors could occur at different stages of PostIt's operation. Level 4 errors are associated with the overlay file system. Their report should be pretty clear in what the error is and you should be able to easily figure out how to remedy the situation. ┌────────────────────────────────────────────────────────────────────────────┐ │░░░▒▒▒▓▓▓ The Legalities ▓▓▓▒▒▒░░░│ └────────────────────────────────────────────────────────────────────────────┘ "PostIt" refers to the executable programs and documentation contained in the PostIt Textfile -> Message Utility distribution archive and the actual distribution archive created by Mark Lewis and Quartz Crystal Software. PostIt is the copyrighted material of Mark Lewis and Quartz Crystal Software. It may only be used in accordance with the conditions set out in this license agreement. You may use PostIt for a period of thirty days on a trial basis in order to determine it's suitability for your particular application. After this period you MUST register your copy of PostIt. Registration entitles you to use PostIt and any future versions of PostIt that may be released for public consumption for as long as you wish, subject to any special licensing conditions attached to future versions. For details on registering PostIt, please refer to the section "HOW TO REGISTER" located elsewhere in this document or to the POSTIT.REG file in the original archive. Mark Lewis and Quartz Crystal Software are in no way obligated to provide future versions of, or support for, PostIt. Site and Group registrations are available, and are dealt with on a case by case basis. You may not modify or otherwise reverse-engineer PostIt. This includes the documentation provided and the original distribution archive. You are encouraged to distribute PostIt provided that no fee is charged for its distribution, and that the distribution archive is not modified from it's original form in any way. Pay Bulletin Board Systems may, however, charge their normal fee provided that no additional charge for PostIt is levied. PostIt may not be included as part of any software library which is distributed on a commercial basis (commercial = "for money") without prior written permission from Mark Lewis and Quartz Crystal Software. PostIt may not be used in any unlawful or illegal manner. Mark Lewis' and Quartz Crystal Software's liability resulting from your use or inability to use PostIt is limited to the amount that the affected party has paid for it, or in the event that PostIt was registered with a third party for payment to Mark Lewis and Quartz Crystal Software, liability is limited to the amount that was received by Mark Lewis and Quartz Crystal Software from that third party. ┌────────────────────────────────────────────────────────────────────────────┐ │░░░▒▒▒▓▓▓ How To Register ▓▓▓▒▒▒░░░│ └────────────────────────────────────────────────────────────────────────────┘ PostIt may be registered by sending $10.00 in US funds for each copy being purchased and the completed Licensing Registration Form to the following address. Sorry, only Money Orders and Bank/Cashiers Checks can be accepted. I wish that I could handle other countries currencies but at this time, it's not something that is available. In the future, Quartz Crystal Software does expect to be able to handle foreign currency. You are not encouraged to send Cash thru the postal system but it will also be accepted if received. You will receive a Licensing Key that will enable you to continue to use PostIt for as long as you wish. There are no added features in PostIt that will be enabled by registering. Your Licensing Key will be delivered via postal delivery if you do not have a FIDONet Network address or if you are located outside of North America. If you do have a FIDO address and are located in North America, your licensing key will be delivered via Direct Netmail to the FIDONet address specified on the Licensing Registration Form. Mark Lewis and Quartz Crystal Software cannot be held responsible for registration fees received without a completed Licensing Registration Form. PostIt Registrations 551 Indian Creek Estates Goldston, NC 27252 Make Checks and Money Orders payable to Quartz Crystal Software. Other registrations sites may be available in the future. If you are interested in becoming a QCS Support and/or Registration Site, please contact Mark Lewis or one of the existing Support Sites. Special arrangements for key delivery may also be made by contacting Mark or a Support Site. ┌────────────────────────────────────────────────────────────────────────────┐ │░░░▒▒▒▓▓▓ Licensing Registration Form ▓▓▓▒▒▒░░░│ └────────────────────────────────────────────────────────────────────────────┘ ( Please Print Clearly - Some of this information is used to calculate your ) ( licensing key. I cannot provide a key if I cannot read what you write. ) Name : ______________________________________________________________________ Mailing Address : ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ BBS Name : ____________________ BBS Phone Number : ________________________ FIDONet Address : _____________ Voice Phone Number : ________________________ Payment Method : ___ Money Order ___ Check Number of Copies : _____ Total Payment : ___________ US Funds. ┌────────────────────────────────────────────────────────────────────────────┐ │░░░▒▒▒▓▓▓ Beta Team Members ▓▓▓▒▒▒░░░│ └────────────────────────────────────────────────────────────────────────────┘ Thomas Smith The Dark Tower Lawrence KS 1-913-841-1700 1:299/500 Eric Staufer The Concession Stand Vero Beach FL 1-407-569-6568 1:374/6568 Len Emery Shorelines BBS West Haven CT 1-203-931-1853 1:141/680 Chris Griffin Dosadi Experiment Wethersfield CT 1-203-257-9906 1:142/906 Scott Wilkos The Space Bar Cromwell CT 1-203-635-7955 1:320/89 Rob Hood Rogue's Morgue BBS... S. Wheelock VT 1-802-626-5956 1:325/804 Rick Wilson The Northland Connection Putnam CT 1-203-963-1187 1:327/2112 Jeff Coe The Bear Den BBS Garden City MO 1-816-331-8358 1:280/74 ┌────────────────────────────────────────────────────────────────────────────┐ │░░░▒▒▒▓▓▓ Acknowledgments and Credits ▓▓▓▒▒▒░░░│ └────────────────────────────────────────────────────────────────────────────┘ Firstly, my thanks and appreciation to the members of the QCS Beta Team that worked on this project. You've all done an excellent job! Thanks! Thanks also go to Mark May for his excellent work and his MKMSG library code without which PostIt would have never been done. I'd also like to thank Andrew Milner for his excellent RemoteAccess BBS software. Without it, I'd not have had a need to write PostIt. JAM(mbp) - Copyright 1993 Joaquim Homrighausen, Andrew Milner, Mats Birch, Mats Wallin. ALL RIGHTS RESERVED. RemoteAccess - Copyright (C) 1989-1993 Wantree Development & Andrew Milner MBUtil and GEcho - Copyright Gerard van der land FMail and FTools - Copyright Folkert Wijnstra Squish - trademark of Scott J. Dudley Other copyrighted works mentioned in this document and not specifically mentioned here are copyrighted by their respective copyright holders. (duh!)